The ‘state of the art’ in the computer software industry remains such that software is often delivered with various anomalies in its desired behavior. These anomalous behaviors have come to be called “bugs”.
The original computer bug is in the operations log of the Harvard University Mark II Aiken Relay Calculator, now preserved in the Smithsonian. The operators removed a moth that had become trapped between relay switches in the computer, and wrote the entry “First actual case of bug being found.” Problems with computer hardware and software have since been called “bugs”, with the process of removing problems called “debugging”.
Each time software is “debugged”, a change to that piece of software is created—this change sometimes results in an additional piece of software called a “patch” or “fix”. The industry's software vendors often call these patches by the more formal names “Service Packs” or “Support Packs.”
This process has become so prevalent in the industry that software vendors use various naming and numbering schemes to keep track of their available “Support Packs”. The difficulty of keeping these “Support Packs” straight is increased when vendors fail to agree on a standard scheme of naming and numbering.
Microsoft, for instance, for its Windows NT family of operating system software products has no less than six major “Service Packs” available to be applied to solve problems its customers may experience. More generally, the total number of patches, fixes, solutions, and/or service packs for any given operating system may be enormous.
When an application is installed, it may contain one or more of these operating systems file patches along with the standard computer files. The patches are generally included because the application vendor discovered some anomalous behavior in one or more of the operating system files, and so sent a “fix” in the form of a different version of one of these troublesome files. This would cause relatively little difficulty if only one application vendor performed this service, or if the file modified by the application vendor is used only by that vendor's application. However, this is often not the case.
When another application is installed, that application may include a more recent version of a shared piece of code. One subset of these shared operating system files are called DLL's (dynamically linked libraries), though they also go by other names. These shared operating system files are often executable, and they expect a fixed number of parameters, certain kinds of parameters, and so on. If the nature of the shared file has changed (e.g., the parameter set is different, the name is different, the function is different), the calling application may no longer behave correctly. Many common computer functions such as “print” are referenced in this fashion.
Many software vendors try to provide the “latest” version of the operating system file. However, when a different application is loaded onto a computer, it may overwrite and subtly (or not-so-subtly) change an operating system file that the original application needed to function as planned.
Assume an administrator for an organization is charged with keeping one hundred servers up and running while supporting three thousand users connecting to these servers. The administrator is also responsible for installing user requested or management dictated applications—either shrink wrapped purchases or internally developed applications. The administrator also has responsibility for the timely distribution, locally or remotely, of time sensitive documents.
Now imagine that six service packs must be installed on the network and distributed to all of the clients. Applying the six service packs could easily result in seven visits to each and every one of the hundred servers for a total of seven hundred visits. This number assumes one extra visit per machine because the application of one of the service packs may cause more problems than it fixed, so it had to be undone.
If the three thousand clients were all running the same workstation operating system, that could mean another twenty-one thousand visits to apply the patches. Remember this all has to be accomplished while installing and patching the internally developed applications and the shrink-wrapped products. Distribution of software patches and files and their subsequent application becomes the first indication of what might be called “administrator agony”.
While all the installation is occurring, the individual servers must still be monitored. When a server needs attention the administrator is often contacted by another person, who may frantically report that their server is down and must be fixed. If the administrator had some method to monitor these devices, he or she could become more responsive and further reduce the impact of problems. Monitoring needs are a second indication of “administrator agony”. There is often high turnover in the administrator's job, and the users of these systems may experience lower productivity.
Traditionally, the administrator had been helped by being given extra staff. Of course this remedy is not without problems—the addition of personnel increases the number of communication channels between them. The people involved in installation and updates need a tracking device or system so they don't perform or attempt to perform the same unit of work. This lack of coordination between team members is a third indication of “administrator agony”.
Proposed solutions are currently available in varying forms, implementations, and coverage or completeness. Typically these proposed solutions are available as shrink-wrap products that are installable (e.g., patchable) locally in the administrator's environment. Some emerging products are helpful, but many conventional solutions are invasive in that they require massive modification of the administrator's environment. The shrink-wrap solution requires additional invasive full product installations in the administrator's network, thereby adding to the problem, and lacks a central “command center” to coordinate the support or distribution plan. Emerging solutions may provide a somewhat lesser degree of invasion, but nonetheless require a special connection between the administrator and the solution, and they often do not provide a center for coordinated efforts.
Furthermore, it is not always obvious exactly what patches, if any, a given piece of software has received. Updates don't always clearly announce their presence. So, it is not always clear whether a specific computer has previously received a specific patch. Accordingly, there is a need for improved tools and techniques for updating computers across a network. Such tools and techniques are described and claimed herein.